Fix for duplicate type field in ELM JSON #1403
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
ChoiceTypeSpecifier
ELM node has a deprecatedtype
element which, if not null, clashes with the"type" : "ChoiceTypeSpecifier"
field in the JSON serialisation of the node. This does not happen in the XML serialisation which nests<type>
tags inside<ChoiceTypeSpecifier>
.Because the
type
element is deprecated, it is not normally populated by the compiler anymore and stays null in the ChoiceTypeSpecifier instance. It is however set to an empty list if you just callChoiceTypeSpecifier.getType()
(which we do during the ELM optimisation stage in the compiler).This PR adds a new
REMOVE_CHOICE_TYPE_SPECIFIER_TYPE_IF_EMPTY
edit to phase 5 of compilation. The edit "protects" the downstream JSON serialisation if it can be done without data loss.I also changed the
ensureNoDirectElmConstruction
ArchUnit test to allow direct ELM construction in Java tests. This allowed me to instantiate ELM nodes (only in the tests) in a quick way without using the object factory.Closes #1380.